Diagnostic application programs, also called “diagnostics,” provide functionality for testing components in a computer system. Typical diagnostics include a console program that allows a user to control the operation of the diagnostics and one or more diagnostics modules that perform the actual diagnostic tests. Diagnostics modules are available that can test virtually all of the components in a computer system. For instance, diagnostic modules exist for testing the operation of central processing units, main memory, mass storage devices, video cards, input/output devices, network devices, and other components of a computer system.
In order to provide a high level of feedback to a user during the execution of a diagnostic module, a large number of messages are typically generated by the diagnostics module that describe its current status. For instance, diagnostic status messages may be generated identifying the diagnostic activity currently taking place, the status of the diagnostic activity, the percentage completed, and whether the diagnostic module has completed its processing.
In order to present the diagnostic status messages to a user of the diagnostics, the diagnostic modules typically communicate with the console program over a proprietary or legacy interface. Through such an interface the diagnostics modules can transmit diagnostic status messages to the console which may then be displayed to the user by the console. Although a proprietary or legacy interface allows messages to be exchanged easily between a console and diagnostics modules, such an interface prohibits access to the messages by external applications. For instance, a user that would like to use a third-party console program to interact with diagnostics modules provided by another manufacturer would typically be unable to do so due to the incompatible interfaces between the console program and diagnostics modules.
One way console programs can be used with diagnostics modules created by different manufacturers is through the use of a management platform, such as the Common Diagnostic Model (“CDM”). CDM defines standard enabling building blocks that allow “plug-in” diagnostics modules to be integrated with console programs, also called management applications. This allows management applications to execute diagnostics modules meant for different devices, and provided by different manufacturers, over a single, uniform, and consistent interface. The CDM architecture is scalable and applicable to many platforms.
While CDM allows diagnostics modules provided by different manufacturers to be utilized with virtually any management application, the CDM platform is not without its drawbacks. One such drawback arises from the fact that diagnostics modules that communicate with a console program via a proprietary or legacy interface are not compatible with CDM. In order to make such diagnostics modules compatible with CDM, they must be rewritten. However, rewriting a diagnostics module for compatibility with CDM can be a time consuming and expensive process.
Another drawback to CDM is caused by the mechanism utilized by CDM to handle the reporting of diagnostic status messages. CDM utilizes a diagnostics results object that is periodically populated with information regarding the status of the diagnostic. In order to retrieve the data from the results object, the object must be periodically polled by the console program, or management application, to retrieve the data. Because this mechanism requires that data be “pulled” from the results object, it suffers from a number of serious drawbacks.
For instance, use of CDM's mechanism for polling a results object may result in an unnecessary poll of the results object when no data is available, an unnecessary poll of the results object when the results data has not changed since the last poll, and may result in important data being ignored until the next time the results object is polled. In this scenario, the test status is updated based on the time interval of the polling, rather than at a rate dictated by the diagnostic itself.
Therefore, in light of the above, there is a need for a diagnostic application program that can interface legacy diagnostic modules with a standard instrumentation platform without modification of the legacy modules. There is also a need for a diagnostic application program that can generate diagnostic event messages to an instrumentation platform concurrent with the execution of a diagnostic module that does not require polling of a results object to receive the event messages.